deployer/requirements/config/set.php (1)

111-113: requirements_check_health_enabled is misplaced relative to the other requirements_check_*_enabled flags

All other per-category enable flags are grouped together at lines 11–20. requirements_check_health_enabled is placed far down the file next to the URL config. Keeping it with the other flags improves discoverability and consistency.

♻️ Proposed fix

 set('requirements_check_database_grants_enabled', true);
+set('requirements_check_health_enabled', true);
 
 // Locales

 // Health check
-set('requirements_check_health_enabled', true);
 set('requirements_health_url', 'http://localhost');

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@deployer/requirements/config/set.php` around lines 111 - 113, Move the
set('requirements_check_health_enabled', true) so it sits with the other
per-category enable flags (the group of set('requirements_check_*_enabled')
entries) instead of next to the URL; leave set('requirements_health_url',
'http://localhost') in its current location. Edit the file to relocate the
requirements_check_health_enabled flag into the enable-flags block (alongside
the other requirements_check_*_enabled settings) to improve consistency and
discoverability, ensuring no other keys or order-dependent logic are changed.

deployer/requirements/task/health.php (1)

71-72: HTTP 4xx responses classified as REQUIREMENT_OK — consider adding a clarifying comment

$httpCode >= 200 && $httpCode < 500 marks all 2xx, 3xx, and 4xx responses as healthy. For a "is the server responding at all" check this is reasonable, but a 404 from the configured URL could mask a misconfigured requirements_health_url. A short inline comment documenting the intent would prevent future confusion.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@deployer/requirements/task/health.php` around lines 71 - 72, The HTTP status
check in health.php currently treats any $httpCode >= 200 && $httpCode < 500
(2xx–4xx) as REQUIREMENT_OK which can hide misconfigured
requirements_health_url; update the code around the conditional that calls
addRequirementRow('HTTP response', REQUIREMENT_OK, "HTTP $httpCode from $url")
to include a short inline comment explaining the intent (e.g., that 4xx
responses mean the server responded but the resource may be missing and
therefore are considered "server reachable" for this health check) so future
maintainers understand why 4xx are acceptable here; mention the relevant symbols
$httpCode, $url, addRequirementRow and REQUIREMENT_OK in the comment.

deployer/requirements/functions.php (1)

362-374: pgrep is never tried when systemctl is in PATH but non-functional (e.g., containers)

The elseif means pgrep is only used when systemctl is entirely absent. If the target host has the systemctl binary in PATH (e.g., an Ubuntu/Debian image or VM where systemd isn't PID 1), $hasSystemctl is true, systemctl is-active returns empty / "failed" output (stderr is discarded), $status !== 'active', and the function iterates through all names and returns null — pgrep is never attempted. The docblock says "pgrep fallback" but the implementation provides it only at the system level, not the per-service level.

Consider falling through to pgrep whenever systemctl doesn't confirm the service is active:

♻️ Proposed fix

         if ($hasSystemctl) {
             $status = trim(run("systemctl is-active $name 2>/dev/null || true"));
 
             if ($status === 'active') {
                 return $name;
             }
-        } elseif (test("pgrep -x $name > /dev/null 2>&1")) {
-            return $name;
-        }
+        }
+
+        // Fallback: pgrep when systemctl is absent, non-functional, or the
+        // service isn't registered as a systemd unit but the process is running.
+        if (!$hasSystemctl || $status === 'unknown' || $status === '') {
+            if (test("pgrep -x $name > /dev/null 2>&1")) {
+                return $name;
+            }
+        }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@deployer/requirements/functions.php` around lines 362 - 374, The code uses
elseif so pgrep is only attempted when systemctl is completely absent; change
the flow to try pgrep per-service whenever systemctl exists but does not report
the service as active. Concretely, in the loop that sets $status via
run("systemctl is-active $name...") (and uses $hasSystemctl), replace the elseif
branch with a separate if that runs test("pgrep -x $name > /dev/null 2>&1") when
either $hasSystemctl is false or when $hasSystemctl is true but $status !==
'active' (i.e., fall through to pgrep if systemctl didn't confirm active).
Ensure you reference the same variables ($hasSystemctl, $status, $name) and
commands (systemctl is-active, pgrep -x) so the per-service pgrep fallback
executes correctly.